Signaling in current cellular communications systems (e.g., 3rd Generation Partnership Project (3GPP) based systems) is based on associating a bearer (a logical and/or physical communications channel for communicating information between to points) with a complex Quality of Service (QoS) profile that includes many parameters describing desired QoS characteristics of the bearer. FIG. 1, taken from the 3GPP Technical Specification (TS) 23.107 in the context of Universal Mobile Telecommunications Services (UMTS), shows examples of different layers of bearer services. A bearer service is a communications service that provides the capability for the transmission of signals between access points.
Bearers are realized on several levels in FIG. 1. There is a physical radio bearer service between a Mobile Terminal (MT) and a Radio Access Network (RAN) and a physical bearer service between the RAN and a Core Network (CN) node, like a Serving GPRS Support Node (SGSN). There is a radio bearer service between the MT and RAN, and an access bearer service between the RAN and the SGSN. Also at that level is a backbone bearer service between the SGSN and a CN gateway, like a Gateway GPRS Support Node (GGSN). A Radio Access Bearer (RAB) service extends between the MT and SGSN, and a backbone bearer service extends between the SGSN and the GGSN. There is a Terminal Equipment (TE)-to-MT bearer service, and a UMTS bearer service from the MT to the GGSN. That layer also includes an external bearer service between the GGSN and the other end of the connection TE. The top layer is the end-to-end service between the two TEs.
Between a user equipment (UE) (UE=TE+MT) and the GGSN, a packet data protocol (PDP) context is established, corresponding to the UMTS Bearer Service in FIG. 1. The PDP context is a data structure present on the SGSN, the GGSN, and the UE which contains a subscriber's communication session information when the subscriber has an active communication session herein referred to as a “connection.” When a mobile terminal wants to use the bearer services in FIG. 1, it must first attach to the network and then activate a PDP context. The attach procedure allocates a PDP context data structure in the SGSN located where the subscriber is attaching and the GGSN serving the subscriber's access point. The data recorded includes a subscriber's IP address, International Mobile Subscriber Identifier (IMSI), and Tunnel Endpoint ID (TEID) at the GGSN and SGSN. A TEID is a number allocated by the GPRS support node (GSN) (both the SGSN and GGSN are GSNs) which identifies the tunneled data related to a particular PDP context.
A 3GPP QoS profile is employed to define the quality of service provided for a PDP context and a RAB. Accordingly, differentiated treatment of packet data traffic is based on setting up different bearers with different QoS profiles and mapping traffic to these different bearers. There is a movement in 3GPP to replace the relatively complex QoS profile and its numerous QoS parameters with a simpler QoS Class Identifier (QCI). The intent for the QCI is to not include the actual characteristics of a bearer, but instead merely provide a pointer to provisioned (preconfigured) traffic forwarding policies stored and enforced in various nodes that support the bearer (including the Radio Network Controller (RNC)). Accordingly, the QCI is simpler to signal and requires less bandwidth than the QoS profile. And as appreciated by the inventors, the QCI opens up new opportunities to differentiate the traffic in other ways than what is possible with current 3GPP QoS parameters.
During the lifetime of a PDP context and its associated RAB, the mobile radio connection can be operate at different activity level states with respect to the radio resources assigned to it. In UMTS, for example, when a mobile is in a connected mode, it can assume one of four radio resource control (RRC) connection states which define what kind of physical channel a UE is using. In a Cell_DCH state, a dedicated physical channel and/or a shared channel (such as in HSDPA) is allocated to the UE. In a Cell_FACH state, no physical channel is allocated for the UE, but random access channels are used instead. The UE uses less battery power compared to the Cell_DCH state but can listen to the broadcast channel to acquire system information. In a Cell_PCH state, the UE's location is known on a cell level, but it can be reached only via the paging channel. The UE battery consumption is less than in the Cell_FACH state. The URA_PCH state is very similar to Cell_PCH state, except that the UE does not execute cell updates, but instead reads registration area IDs from the broadcast channel. Of the four states, the URA_PCH state uses the least amount of battery power.
The 3GPP specification allows the radio network controller (RNC) in the RAN to control transition between these UE activity states based on the activity level of the radio connection. For example, an inactivity timer could be set for one state. When that timer expires, a radio network controller (RNC) node triggers transition in the UE from a current activity state to a lower activity state. Within certain states, e.g., the Cell_PCH and URA_PCH states in WCDMA, it is also possible to set a longer “sleep mode” (low power) cycle length based on the connection activity. The UE battery consumption is lower with a longer sleep mode cycle.
Inactivity timers are statically configured in the RNC node per UE activity state. If packet data transmission is triggered, the latency (i.e., the response time for the mobile to commence substantive data communication) is longer if the radio connection is in a lower activity state than if it is in a higher activity state. For example, in the Cell_DCH state dedicated radio resources are already assigned to the connection. On the other hand, a significant benefit of a lower activity state is lower battery consumption in the UE. So there is a trade-off between latency and power consumption.
Static settings for inactivity timers depend on the projected associated traffic types. Traffic with QoS requirements of the “Interactive” traffic type has a stricter latency requirement for an inactivity timer setting. Web traffic transactions are an example of interactive traffic and have a higher probability of subsequent, follow-on packet data traffic within a short time period, conditioned on the detection of packet data traffic. For example, if a user starts web browsing, it is probable that a new web page will be loaded after the user reads some part of the web page. Once a browsing session is initiated, the user expects short response times (low latency) for subsequent clicking on web page links. Therefore, an inactivity timer for such interactive traffic should be fairly long, (e.g., longer than the average reading time of a web page), allowing quick response times during the web browsing session. Although all inactivity timers could be set to optimize for such interactive traffic type, the inventors realized that there are other types of traffic that do not have the same requirements.
The inventors recognized that for example message-oriented traffic typically has a lower probability of additional transactions within a short time period conditioned on the detection of a single packet data transmission. This traffic type includes, for instance, push e-mail transactions, IP multimedia sub-system (IMS) subscribe/notify mechanisms (such as presence traffic), machine-to-machine metering communication, or instant messages (IM) like SIP Message as well as pure presence traffic like SIP subscribe/notify. Because the probability of additional transmissions is low, requirements on subsequent response times are not so critical. Accordingly, after transmission of a single packet data burst, the radio connection should soon return to a lower activity state in order to save UE battery power. Consequently, an inactivity timer should be set shorter for message-oriented traffic so that the timeout occurs sooner and the UE can switch to a lower power consumption state. Still, the trade-off for the lower activity level means higher latency (response time), so the user will have to wait longer than for web-type transactional traffic communications.
So a substantial shortcoming with static inactivity timer settings is that traffic with similar QoS requirements is mapped to the same bearer with the same QoS parameters, even though the traffic may have different latency and/or battery power saving requirements when it comes to an inactivity timer setting. A compromise and less than satisfactory inactivity timer setting could be used for all different types of traffic. Alternatively, traffic with similar QoS requirements but different inactivity timer setting requirements could be separated onto different bearers. Unfortunately, there is no parameter in the current 3GPP QoS profile to indicate the characteristics of the traffic for a differentiated inactivity timer setting. A significant problem then is how to differentiate mobile activity state transitions for different traffic types and allow differentiated balancing between requirements on response time/latency, resource usage, and battery power.